Recently, there are numerous home network middlewares introduced such as home audio video interoperability (HAVI), JINI, LonWorks, home network control protocol and a universal plug and play.
The HAVI was introduced on 1997 by home appliance manufacturers SONY, Phillips and Thomson, and the HAVI has been developed as a standard of audio and video (A/V) network based on high-speed bus employing IEEE 1394. The JINI was developed based on Java technology and requires JVM and RMI technology. The LonWorks was introduced by Echelon Company in U.S., and is a system providing total solution of automation technology supporting various communication medium. The HnCP is a protocol defined based on a power cable MODEM makers such as LG or SAMSUNG electronics in Korea. The UPnP is a middleware defined by an UPnP forum based on Microsoft and it employs TCP/IP based protocol.
These conventional middlewares uses different physical medium and protocols. Therefore, the interoperability is not provided to various devices connected to the middlewares. In order to overcome such a drawback, a conventional gateway is introduced in Korea Patent 10-0413684 entitled “GATEWAY ENABLING DATA COMMUNICATION BETWEEN DEVICE SEARCH HAVING DIFFERENT MIDDLEWARE, HOME NETWORK SYSTEM THEREBY, AND GATEWAY RELAYING METHOD” issued at Dec. 12, 2003, and It will be described with reference to FIG. 1.
FIG. 1 is a block diagram showing a conventional home-network system.
As shown in FIG. 1, the conventional home-network system includes a first device 100, a second device 110 and a gateway 120. The first device 100 uses a first middleware employing HAVI, and the second device 110 uses a second middleware employing UPNP.
The first device 100 includes a first function module 101 performing own functions; a first middleware 102 for analyzing and transforming messages transmitted or received from/to the first function module 101 according to a predetermined specification; and a first network accessing unit 103 for accessing a network to transmit the message from the first middleware 102, and transferring message received from the network to the first middleware 102 based on IEEE 1394.
The second device 110 includes: a second function module 111 for performing own functions; a second middleware 112 analyzing and transferring message to be transmitted or received to/from the second function module 110 according to a pre-determined specification defined in UPnP; and a second network accessing unit 103 for accessing a network to transmit the message from the second middleware 112 and transferring message received from the network to the second middleware 112 based on TCP/IP.
The gateway 120 relays messages to be exchanged between other devices by including middlewares employed by devices on the network. Such a relaying operation of the gateway 120 is classified into following three steps.
At first step, the first device 100 generates a message to be transmitted to the second device 110 and transmits the generated message to the gateway 120. The gateway 120 includes an arbiter 121, a generic HAVI agent 122, a generic UPnP agent 123, an IEEE 1394 processor 124 and a TCP/IP processor 125. Then, the generic HAVI agent 122 of the gateway 120 analyzes the message from the first device 100, transforms the message to be suitable to the generic UPnP agent 123 and transmits the message to the second device 110 at second step. At third step, the second device 110 processes the message from the gateway 120 and returns the result thereof.
The first device 100 employing the HAVI includes a first function module 100, a HAVI layer 102 and an IEEE 1394 layer. The first function module 101 creates a message that instructs a target function of the second device 110 and transfers the created message to the HAVI layer 102. Then, the HAVI layer 102 transforms the message to be suitable to HAVI specification and transmits the transformed message to the generic HAVI agent 122 of the gateway 120.
The generic HAVI agent 122 of the gateway 120 inquires availability of the second device 110 to the arbiter 121. The arbiter 121 inquires to the generic UPnP agent 123 whether the second device 110 is on the network since the received message is HAVI type.
The generic UPnP agent 123 searches a table in the IEEE 1394 processor 124 to find a name of the second device 110. If the name of the second device 110 is in the table, the generic UPnP agent 123 creates a message denoting that the second device 110 is on the network and transmits the message to the arbiter 121. If the second device 110 is available, the arbiter 121 transmits the message having the command of target function and parameters to the TCP/IP processor 125. The TCP/IP processor 125 transforms the message to be suitable for UPnP middleware specification and transmits the transformed message to the second device 110.
The UPnP layer 112 of the second device 120 analyzes the message received from the TCP/IP processor 125 and transmits the message to the second module 111. The second function module 111 performs the command of the message and returns the result to the arbiter 121 of the gateway 120. The arbiter 121 transmits the result to the first function module 101 of the first device 100.
As described above, the conventional home-network system has following shortcomings although the conventional home-network system provides basic interoperability between devices.
At first, there is no specification defined about how a target device is shown in a device that controls the target device and about the time automatically sensing the target device.
Secondly, middleware messages are transformed through a template of the middleware agent through the middleware agent and the arbiter using various trans-formation methods. Such message transform may be achieved in various methods such as a 1:1 bridge method. The 1:1 bridge method is a suitable method when there are few middlewares existed on the network. However, complexity of a message transforming template dramatically increases in proportional to the number of the middlewares on the network. Therefore, the 1:1 bridge method is not suitable method to transform the middleware messages when there are many different types of middlewares existed. Herein, the complexity of message transforming is {n×(n−1)}/2, where n denotes the number of the home-network middlewares.
Thirdly, a method of finding a device through querying to all middleware agents generates the great number of the packets and causes greater load on the network.
Beside of the three problems, there is no specification for connecting/releasing devices, registering events and generating events in the conventional method of controlling and monitoring devices.